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INTERFACE  SPECIFICATIONS  FOR  THE  SCR  (A-7E) 
APPLICATION  DATA  TYPES  MODULE 


INTRODUCTION 

This  report  specifies  the  abstract  interfaces  for  a  software  module  that  forms  part  of  the  Opera¬ 
tional  Flight  Program  for  the  Navy’s  A-7E  aircraft.  As  the  demonstration  vehicle  for  the  Naval 
Research  Laboratory’s  Software  Cost  Reduction  (SCR)  project,  the  program  is  being  designed  and 
implemented  in  accordance  with  modern  software  engineering  principles  such  as  information-hiding, 
cooperating  sequential  processes,  and  abstract  data  typing. 

The  basic  computing  environment  for  the  application  software  is  provided  by  the  Extended  Com¬ 
puter  module,  specified  in  reference  [EC].  The  Extended  Computer  interface  provides  all  the  facilities 
necessary  for  handling  data,  as  well  as  input/output  (i/o),  sequence,  and  process  control. 

Overview 

The  application  Data  Types  (ADT)  module  provides  facilities  for  handling  those  data  types  which 

(a)  are  useful  to  the  application  at  hand  (in  this  case,  an  embedded  real-time  avionics  program);  and 

(b)  can  be  implemented  independently  of  the  host  computer,  i.e.,  are  not  provided  by  the  Extended 
Computer  Module. 

Although  the  type  classes  provided  by  the  module  are  fixed,  operations  are  available  to  specify 
specific  types  within  a  type  class,  and  to  create  and  manipulate  data  objects  of  each  type.  The  module 
comprises  two  submodules: 

(1)  Numeric  Type  Classes.  This  submodule  provides  those  numeric  data  type  classes  that  are 
considered  to  be  generally  useful  to  avionics  applications;  these  type  classes  are  used  to  represent  physi¬ 
cal  quantities:  acceleration  (both  scalar  and  vector),  angle,  angular  rate,  density,  displacement,  distance, 
pressure,  speed,  and  velocity.  Facilities  are  provided  that  allow  manipulation  of  such  quantities  without 
regard  to  the  units  of  measurement. 

(2)  State  Transition  Event  (STE)  Type  Class.  This  submodule  allows  programs  to  create  and 
operate  on  data  types  described  as  finite  state  machines.  The  domain  of  an  STE  variable  is  a  set  of 
states.  The  changing  of  a  variable’s  state  is  an  event  that  can  be  signaled  and  awaited. 

Reader  Prerequisites 

This  report  is  a  companion  to  Chapter  EC. DATA  of  [EC],  and  it  is  assumed  that  the  reader  is 
familiar  with  that  chapter,  particularly  the  notion  of  type  classes,  specific  types,  and  other  terminology 
used  therein.  The  ADT  interfaces  are  modeled  after  that  submodule  of  the  Extended  Computer.  To 
present  as  concise  a  document  as  possible,  we  frequently  refer  to  that  chapter  rather  that  duplicate 
information  that  appears  there. 

This  report  follows  the  standard  organization  presented  in  [SO],  as  modified  in  the  Introduction  to 
[EC],  and  readers  should  also  be  familiar  with  that. 

Manuscrtpl  approved  April  19,  1983. 
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Referring  to  the  Extended  Computer 

When  a  reference  is  made  to  Chapter  EC.DATA  of  [EC],  the  following  rules  apply: 

(1)  If  the  reference  is  made  to  an  EC.DATA  access  program,  then  the  name  of  the  ADT 
access  program  that  is  being  specified,  as  well  as  the  parameters,  parameter  meanings, 
parameter  requirements,  undesired  events,  undesired  event  dictionary  definitions,  and 
program  effects  will  be  the  same  as  those  given  for  the  access  program  in  EC.DATA, 
except  as  noted. 

(2)  Any  information  about  registers  given  in  a  referenced  section  of  EC.DATA  should  be 
ignored.  This  module  does  not  provide  registers. 


NRL  REPORT  8734 


AT.NUM  NUMERIC  ABSTRACT  DATA  TYPES  AND  OPERATIONS 
AT.NUM.l  Introduction 

AT.NUM.1.1  Overview 

The  type  classes  provided  by  this  submodule  give  a  means  to  represent  and  operate  on  physical 
quantities  (such  as  a  speed  or  an  angle)  without  stating  or  assuming  particular  units  of  measurement. 
Conversion  programs  are  provided  to  convert  the  entity  to  its  real  equivalent,  given  the  unit  of  meas¬ 
urement  desired. 

The  notion  of  type  classes  and  specific  types  is  explaned  in  EC.DATA.1.2.  The  types  provided  by 
this  module,  as  well  as  the  available  units  of  measurement  for  each,  are  listed  in  Table  AT.NUM.a. 


Table  AT.NUM.a  —  Types  Classes  and  Associated  Units 


Type  Class 

Unit 

Unit  Meanings 

accel 

fpss 

Feet  per  second  per  second 

P 

Normal  gravity  acceleration 

accel-vec 

a 

angle 

deg 

Degrees 

cir 

Circles 

rad 

Radians 

Angles  may  also  be  converted  to  a 

sine/cosine  representation 

angrate 

deghour 

Degrees  per  hour 

radsec 

Radians  per  second 

density 

slcuft 

Slugs  per  cubic  foot 

displacement 

b 

distance 

ft 

Feet 

nmi 

Nautical  miles 

pressure 

inhg 

Inches  of  mercury 

speed 

fps 

Feet  per  second 

fpm 

Feet  per  minute 

knot 

Nautical  miles  per  hour 

velocity 

C 

aaccel-vec  is  t  three-dimensional  vector  that  may  be  converted  into  components  of  type 
accel. 

^Displacement  is  a  thi  ec -dimensional  vector  that  may  be  converted  into  components  of 
type  distance 

‘Velocity  ij  a  three-dimensional  vector  that  may  be  converted  into  components  of  type 
speed. 
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Specific  types  in  this  module  are  characterized  only  by  the  range  and  resolution  of  all  entities  of 
that  type.  Specific  types  are  created  via  declarations.  Each  variable  and  constant  must  belong  to  a 
specific  type. 

AT.NUM.1.2  Literals 

A  value  for  a  scalar  type  provided  by  this  module  can  be  specififed  by  using  a  real  literal  and  one 
of  the  conversion  programs  that  convert  real  values  to  numeric  scalar  abstract  types.  The  syntax  is: 

<  program-name,  real-literal  > 

The  syntax  for  real-literal  is  given  in  EC. DATA.  1.3.  The  value  thus  specified  is  that  which  would  be 
returned  by  the  program  were  the  real  given  as  the  input  parameter. 

A  value  for  a  vector  type  can  be  specified  similarly,  by  naming  a  program  that  produces  a  vector 
from  constituent  scalars,  which  are  specified  as  shown  above.  The  syntax  is: 

<  program-name,  scalar-literal,  scalar-literal,  scalar-literal  > 

AT.NUM.2  Interface  Overview 

AT.NUM.2. 1  Declaration  of  Specific  Types 

The  form  is  that  of  the  +  +DCLTYPE+  +  program  described  in  EC.DATA.2.1,  with 

pi  as  described  there; 

p2  a  typeclass  as  described  in  AT.NUM.4; 

p3  an  attribute  as  described  in  AT.NUM.4; 

p4  as  described  there;  and 

pS  a  version  as  described  in  AT.NUM.4. 

AT.NUM.2. 2  Data  Declarations 

AT.NUM.2.2.1  Declaration  of  Variables  and  Constants 

The  form  is  that  of  the  +  +DCLJENTITY  +  +  program  described  in  EC.DATA.2.2.1,  with 
pi  and  p2  as  described  there; 

p3,  if  supplied,  an  attribute  as  described  in  AT.NUM.4;  and 
p4  and  pS  as  described  there. 

AT.NUM.2.2.2  Declaration  of  Arrays 

The  form  is  that  of  the  +  +DCL_ARRAY+  +  program  described  in  EC.DATA.2.2.2,  with 
pi  and  p2  as  described  there; 

p3,  if  supplied,  an  attribute  as  described  in  AT.NUM.4;  and 
p4,  pS,  and  p6  as  described  there. 

AT.NUM.2. 3  Access  Speed  Ranking  of  Data 

The  ADT  module  can  implement  a  "not-slower-than"  relation  between  any  two  variables,  con¬ 
stants,  or  arrays.  The  form  is  that  of  the  +  +RANK_DATA  +  +  program  described  in  EC.DATA.2.3. 
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AT.NVM.2A  Operand  Descriptions 

All  information  in  EC.DATA.2.4  applies,  except  for  information  concerning  registers. 

AT.NUM.2.5  Transfer  Operations 

The  form  is  that  of  the  +SET+  program  described  in  EC. DATA. 2. 5;  pi  and  p2  must  both 
belong  to  the  same  type  class. 

AT.NUM.2.6  Numeric  Operations 

AT. NUM. 2.6.1  Numeric  Comparison  Operations 

All  programs  listed  in  EC.DATA.2.6.1  apply.  Parameters  pi,  p2,  and  p4  (if  given)  must  all 
belong  to  the  same  type  class.  For  operands  of  vector  type  classes,  the  following  program  effects  apply: 

+GT+  p3  =  (pi  -  p2)  is  positive  and  NOT  (pi  =  p2)* 

+GEQ+  p3  =  (pi  =  p2)*  OR  (pi  -  p2)  is  positive 

+  LT+  p3  =  (pi  -  p2)  is  negative  and  NOT  (pi  =  p2)* 

+  LEQ  +  p3  =  (pi  =  p2)*  OR  (pi  -  p2)  is  negative 

AT.NUM.2.6.2  Numeric  Calculations 

All  programs  in  section  EC.DATA. 2.6.2  apply.  The  following  parameter  information  applies: 

Parameters 

+  ADD4-  all  operands  belong  to  the  same  AT-provided  type  class 

+ABSV  + 

+COMPLE  + 

+SUB  + 

+MUL+  one  of  pi  or  p2  real,  the  other  two  operands  belong  to  the  same 

AT-provided  type  class;  or, 

p3  speed;  one  of  pi  and  p2  timeint,  the  other  accel;  or 
p3  distance;  one  of  pi  and  p2  timeint,  the  other  speed;  or 
p3  angle;  one  of  pi  and  p2  timeint,  the  other  angrate;  or 
p3  displacement;  one  of  pi  and  p2  timeint,  the  other  velocity;  or 
p3  velocity;  one  of  pi  and  p2  timeint,  the  other  accel-vec. 

+  DIV+  pi  and  p2  belong  to  same  AT  scalar  type  class  and  p3  real;  or, 

pi  and  p3  belong  to  same  AT-provided  type  class  and  p2  real;  or, 
pi  speed,  p2  timeint,  p3  accel;  or, 

pi  distance,  p2  timeint,  p3  speed;  or, 

pi  angle,  p2  timeint,  p3  angrate;  or, 

pi  speed,  p2  accel,  p3  timeint;  or, 

pi  distance,  p2  speed,  p3  timeint;  or, 

pi  angle,  p2  angrate,  p3  timeint;  or, 

pi  displacement,  p2  timeint,  p3  velocity;  or, 

pi  velocity,  p2  timeintt  p3  accel-vec; 

p4  (if  supplied)  same  type  as  p3 
p5  (if  supplied)  same  type  as  p3 

•Equality  is  defined  in  EC. DATA, 2.6,1.  , 
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Program  Effects 

Any  result  of  type  angle  is  taken  modulo  360  degrees. 


+  MUL+  For  multiplying  a  velocity  (accel-vec)  by  a  timeint:  p3  =  a  displacement  (velocity)  vector 
with  the  same  direction  as  the  velocity  (accel-vec),  whose  magnitude  is  equal  to  the 
timeint  multiplied  by  the  magnitude  of  the  velocity  (accel-vec). 

+  DIV+  For  dividing  a  displacement  (velocity)  by  a  timeint:  p3  —  a  velocity  (accel-vec)  vector  with 
the  same  direction  as  the  displacement,  whose  magnitude  is  equal  to  the  magnitude  of  the 
displacement  (velocity)  divided  by  the  timeint. 

Program  effects  for  all  other  cases  are  defined  in  EC.DATA.2.6.2. 

AT.NUM.2.6.3  Operations  Converting  from  AT-Provided  Scalar  Types  to  Reals 


Program  name 

Parm  info 

Undesired  events 

+  R  ACCEL  FPSS  + 

+  RACCELG  + 

pl:accel;I 

p2:real;0 

source 

destination 

%range  exceeded% 

+  R  ANGLE  DEG  + 

+  R  ANGLE  CIR  + 

+  R  ANGLE  RAD  + 

+R  ANGLE  SIN  + 

+  RANGLECOS  + 

p  1  :angle;I 
p2:real;0 

source 

destination 

+R  ANGRATE  DEGHOUR+ 

+  RANGRATERADSEC  + 

pl:angrate;I 

p2:real;0 

source 

destination 

+  RDENSITYSLCUFT + 

pl:density;l 

p2:real;0 

source 

destination 

+  R  DISTANCE  FT  + 

+  RDISTANCENMI  + 

pi  :distance;I 
p2:real;0 

source 

destination 

+  RPRESSUREINHG  + 

pi: pressure; I 
p2:real;0 

source 

destination 

%range  exceeded% 

+  R  SPEED  FPS  + 

+R  SPEED  FPM  + 

+  R  SPEED  KNOT  + 

pl:speed;I 

p2:real;0 

source 

destination 

Program  Effects 


Each  program  provides  a  real  value  in  p2  giving  the  physical  quantity  of  pi  in  the  units  abbreviated  in 
the  name  of  the  program.  The  unit  abbreviations  are  define  in  Table  AT.NUM.a. 
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AT.NUM.2.6.4  Operations  Converting  from  Reals  to  AT-Provided  Scalar  Types 


Program  name 

Parm  tvoe 

Parm  info 

Undesired  events 

+  ACCEL  R  FPSS  + 

+  ACCELRG  + 

pl:reaf;f 

p2:accel;0 

source 

destination 

%range  exceeded% 

+  ANGLE  R  DEG  + 

+  ANGLE  R  C1R  + 

+  ANGLERR AD  + 

pl:real;l 

p2:angle;0 

source 

destination 

+  ANGLE  R  S1N  + 

+ ANGLERCOS+ 

pl:real;I 

p2:angle;0 

source 

destination 

%illegal  sin 
or  cos  given% 

+  ANGLE  R  SINCOS  + 

p  1  :real;I 
p2:real;I 
p3:angle;0 

sine  of  angle 
cosine  of  angle 
destination 

“/orange  exceeded% 

+ ANGRATE  R  DEGHOUR+ 

+  ANGRATE  R  RADSEC  + 

p  1  :real;l 
p2:angrate;0 

source 

destination 

+  DENSITYRSLCUFT  + 

pi  :real;I 
p2:density;0 

source 

destination 

+  DISTANCE  R  FT  + 

+  DISTANCE_R_NMI  + 

pl:real;I 

p2:distance;0 

source 

destination 

+  PRESSURER1NHG  + 

pl:real;I 

p2:pressure;0 

source 

destination 

+ SPEED  R  FPS  + 
+SPEED_R_FPM  + 

pl:real;I 

p2:speed;0 

source 

destination 

+SPEED_R_KNOT  + 


gram  Effects 


+  ANGLE  R  SINCOS  +  Produces  in  p3  the  angle  whose  sine  and  cosine  are 

equivalent  to  pi  and  p2,  respectively. 


+  ANGLERCOS  +  Produces  in  p2  the  angle  between  0  degrees  and 

180  degrees,  inclusive,  whose  cosine  is  pi. 

+  ANGLERSIN  +  Produces  in  p2  the  angle  between  -90  degrees  and 

+90  degrees,  inclusive,  whose  sine  is  pi. 

All  other  programs  produce  an  AT-type  value  in  p2  equivalent  to  pi,  assuming  that  pi  represents  a 
physical  quantity  in  the  units  abbreviated  in  the  program  name.  The  unit  abbreviations  are  defined  in 
Table  AT.NUM.a.  Results  of  type  angle  are  given  modulo  360  degrees. 
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AT.NUM.2.6.5  Operations  Converting  from  Vector  Types 


Program  name 

Parm  type 

Parm  info 

Undesired  events 

+  XYZ_VECTOR  + 

Pi: _ 

;I 

!  + vector +! 

%range  exceeded% 

P2: _ 

;0 

!  +  X  component +  ! 

p3: _ 

;0 

!  +  Y  component +! 

p4: _ 

_ ;0 

!+Z  component-)- ! 

+SPHER_VECTOR  + 

pl:_ 

,1 

!+ vector +! 

p2: _ 

_;0 

!  + magnitude -H 

p3:angle;0 

!+ theta +! 

p4:angle;0 

!+phi  +  ! 

+C  YLVECTOR  4- 

pl: _ 

!  +  vector +  ! 

p2: _ 

,0 

!  + radius  +  ! 

p3:angle;0 

!+ theta +! 

p4: _ 

_;0 

!+Z  component-f ! 

Parameter  Requirements 


+XYZVECTOR+  pi  velocity,  and  p2,  p3,  p4  speed;  or, 

pi  displacement,  and  p2,  p3,  p4  distance;  or, 
pi  accel-vec,  and  p2,  p3,  p4  accel 


+SPHER_VECTOR+  pi  velocity,  and  p2  speed;  or, 

pi  displacement,  and  p2  distance;  or, 
pi  accel-vec,  and  p2  accel 

+CYL_VECTOR+  pi  velocity,  and  p2  and  p4  speed;  or, 

pi  displacement,  and  p2  and  p4  distance;  or, 
pi  accel-vec,  and  p2  and  p4  accel 


Program  Effects 

All  programs  produce  component  equivalents  from  the  given  vector.  No  coordinate  system  frame  of 
reference  is  assumed  by  this  module;  the  frame  of  reference  that  users  employed  to  initialize  the  vector 
will  be  the  one  to  which  the  components  correspond. 

+XYZ_VECTOR+  p2,  p3,  and  p4  are  set  to  the  x,  y,  and  z  Cartesian 

components  (respectively)  of  the  vector  given  by  pi. 

+SPHER_VECTOR+  p2,  p3,  and  p4  are  set  to  the  spherical  coordinate 

components  of  the  vector  given  by  pi. 


+CYL  VECTOR + 


p2,  p3,  and  p4  are  set  to  the  cylindrical  coordinate 
components  of  the  vector  given  by  pi . 
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AT.NUM.2.6.6  Operations  Converting  to  Vector  Types 


Program  name 

+  VECTOR_XYZ  + 

Parm  type  Parm  info  Undesired  events 

d1:  ;I  !  +  X  component +  !  %range  exceeded% 

p2:  ;I  !  +  Y  component  +  ! 

p3:  ;I  !+Z  component +  ! 

p4:  ;0  !  + vector +  ! 

+  VECTOR_SPHER  + 

pi:  ;I  !  + magnitude +  ! 

p2:angle;I  !+ theta +! 

p3:angle;I  !  +  phi  +  ! 

p4:  ;0  !  + vector +! 

+  VECTORCYL  + 

pi:  ;I  !+radius+! 

p2:angle;I  !+ theta  +  ! 

p3:  ;I  !+Z  component +! 

p4:  ;0  !+vector+! 

Parameter  requirements 

+VECTORXYZ+ 

pi,  p2,  p3  speed  and  p4  velocity;  or, 
pi,  p2,  p3  distance  and  p4  displacement;  or, 
pi,  p2,  p3  accel  and  p4  accel-vec 

+  VECTORSPHER  + 

pi  speed  and  p4  velocity;  or, 
pi  distance  and  p4  displacement;  or, 
pi  accel  and  p4  accel-vec 

+  VECTORC  YL  + 

pi  and  p3  speed,  and  p4  velocity;  or, 
pi  and  p3  distance,  and  p4  displacement;  or, 
pi  and  p3  accel,  and  p4  accel-vec 

Program  Effects 

+  VECTOR_XYZ+ 

• 

p4  —  the  vector  equivalent  of  pi,  p2,  and  p3, 
assuming  a  Cartesian  coordinate  system. 

+VECTORJSPHER  + 

p4  —  the  vector  equivalent  of  pi,  p2,  and  p3, 
assuming  a  spherical  coordinate  system. 

+  VECTOR_CYL  + 

p4  —  the  vector  equivalent  of  pi,  p2,  and  p3, 
assuming  a  cylindrical  coordinate  system. 

AT.NUM.3  Undesired  Event  Assumptions 

See  EC. DATA. 3.  All  Undesired  Event  assumptions  there  apply,  except  for  those  that  explicitly 
mention  bitstrings,  registers,  or  time  intervals.  In  addition: 

1.  User  programs  will  not  provide  a  real  with  magnitude  greater  than  1  to  represent  a  sine  or 
a  cosine  of  an  angle. 


V 
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AT.NUM.4  Local  Type  Definitions 

Local  types  used  in  the  description  of  programs  specified  in  EC. DATA  are  defined  in  Section 

EC.DATA.4,  except  for  the  following: 

attribute  An  ordered  triple  of  numeric  entities  specifying 

lower  bound,  upper  bound,  and  resolution. 

type  class  Enumerated:  accel,  accel-vec,  angle,  angrate, 

density,  displacement,  distance,  pressure,  speed,  or 
velocity. 

version  A  version  name  applicable  to  the  given  type  class. 

Version  names  and  characteristics  are  listed  in 
Appendix  S. 

AT.NUM.5  Dictionary 

Dictionary  terms  used  to  described  programs  specified  in  EC.DATA  are  defined  in  Section 

EC.DATA.5.  The  following  terms  are  introduced  by  this  module: 

!+ magnitude  +  !  The  scalar  magnitude  of  the  vector;  the  distance 

between  the  end  of  the  vector  and  the  origin  of  the 
coordinate  system. 

!+phi-H  In  spherical  coordinates,  the  angle  between  the 

vector  and  positive  z  axis;  sign  of  the  angle  is  the 
sign  of  the  vector’s  z  component. 

!+ radius +!  The  distance  from  the  origin  to  the  end  of  the 

projection  into  the  x-y  plane  of  the  vector. 

!+ theta +!  The  angle  from  the  positive  xaxis  to  the  projection 

of  the  vector  into  the  x-y  plane;  the  angle  is 
measured  counterclockwise  as  seen  looking  into  the 
x-y  plane  in  the  negative  z direction. 

!+ vector +!  The  vector  type  class  equivalent  of  the  given 

components. 

!+X  component +!  The  x  component  of  the  given  vector. 

! + Y  component-!- !  The  y  component  of  the  given  vector. 

! +Z  component-!- !  The  z  component  of  the  given  vector. 

AT.NUM.6  Undesired  Event  Dictionary 

Undesired  events  described  in  programs  specified  in  EC.DATA. 2  are  defined  in  Section 

EC. DATA. 6.  in  addition: 
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%range  exceeded0/)  Defined  in  EC.DATA.6 

%illegal  sin  or  cos  given%  User  has  supplied  a  sine  or  cosine  with 

magnitude  greater  than  1. 

AT.NUM.7  System  Generation  Parameters 

None 

AT.NUM.8  Information  Hidden 

1.  The  representation  of  numeric  objects. 

2.  How  range  and  resolution  information  are  used  to  determine  representation. 

3.  The  procedures  for  performing  numeric  operations. 

4.  Conversions  required,  if  two  objects  of  the  same  type  or  type  class  are  not  represented  in 
the  same  way. 


11 


1 


CLEMENTS,  FAULK,  AND  PARNAS 

AT.STE  STATE  TRANSITION  EVENT  TYPE  CLASS 
AT.STE.l  Introduction 

AT.STE. 1. 1  Overview 


This  module  implements  State  Transition  Event  (STE)  types.  Users  may  define  specific  types  of 
this  type  class  and  declare  entities  of  those  types. 

Each  STE  type  is  a  class  of  equivalent  finite  state  machines.  The  value  of  an  STE  variable  is  its 
state.  Each  STE  type  is  characterized  by  a  set  of  states,  named  subsets  of  that  set,  named  relations  on 
that  set,  and  state  transition  events.  It  is  intended  that  this  module  be  used  only  when  the  number  of 
states  is  small  enough  that  the  attributes  of  the  type  can  be  described  by  enumeration. 

The  relations  may  be  used  either  to  specify  conditions  relating  two  entities  of  the  same  STE  type 
or  to  describe  state  transitions. 

This  module  provides  facilities  that  allow  a  process  to  await  specified  conditions  and  transitions. 
Awaiting  a  state  transition  event  suspends  the  process  until  the  event  occurs.  Awaiting  a  condition 
suspends  the  process  until  the  condition  holds. 

AT.STE.  1.2  Literals 

Literals  are  state  names  and  must  begin  and  end  with  the  character 
AT.STE.2  Interface  Overview 


AT.STE.  2.1  Declaration  of  Specific  Types 


STE  types  are  declared  by  use  of  the  form  of  + +DCLJTYPE+ +  (see  EC.DATA.2.1).  The 
forms  of  the  parameters  for  STE  type  declarations  are  given  below. 


Parameter  Type 


Comments 


pi 

P2 

p3 

p4 

p5 


name 
type  class 
attributes 
binding 

implementation 


any  unused  name 
"STE" 

see  AT.STE.4 

all  STE  attributes  must  be  fixed 
omitted 

Program  Effects 


In  addition  to  defining  a  type,  the  STE  +  +DCL  TYPE+  +  operation  causes  a  number  of  access 
programs  to  be  defined  on  elements  of  the  type  being  declared.  The  syntax  and  semantics  of  these  pro¬ 
grams  are  discussed  in  AT.STE.2. 5. 

The  following  additional  undesired  events  can  occur  in  the  declaration  of  STE  types: 

%%duplicate  set  member%% 

%%malformed  attribute%% 

%%missing  state  attribute%% 

%%too  many  state  attributes%% 

%%type  inconsistency%% 

%%undeclared  spectype%% 

%%unknown  state%% 
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A  T.STE.  2. 2  Declaration  of  Variables  and  Constants 

STE  variables  and  constants  are  defined  by  using  the  form  of  +  +DCL  ENTITY+  +  (see 
EC. DATA. 2. 2).  Parameter  p3  (initial  attribute)  is  omitted  for  STE  type  variables. 

AT.STE.2.3  Declaration  of  Arrays 

Arrays  of  STE  type  entities  are  defined  by  using  the  form  of  +  +  DCL_ARR AY  +  +  (see 
EC.DATA.2.3).  Parameter  p3  (initial  attribute)  is  omitted  for  STE  type  variables. 

AT.STE.2.4  Operand  Descriptions 

See  description  in  EC. DATA. 2.4.  Those  portions  of  the  description  in  EC.DATA.2.4  pertaining 
to  variables  with  varying  attributes,  and  to  registers,  do  not  apply  to  this  module. 

The  following  additional  undesired  event  can  occur  when  operands  are  specified. 

%%inappropriate  parameters%% 

A  T.STE.  2. 5  Access  Programs 

The  declaration  of  an  STE  type  defines  a  number  of  access  programs  that  operate  on  entities  of 
that  type.  For  each  attribute  identifier  that  appears  in  a  "conversion",  "relation",  or  "set"  attribute 
declaration,  an  access  program  is  defined  having  that  identifier  as  its  name.  In  addition,  several  addi¬ 
tional  access  programs  are  defined  whose  names  are  systematically  derived  from  the  attribute  identifiers. 
For  a  given  STE  type  declaration,  the  names  of  the  access  progams  that  are  defined  by  that  declaration 
may  be  found  by  systematically  replacing  the  strings  'set',  'relation’,  ’conversionl',  and  'conversion2' 
with  the  respective  identifier  of  each  set,  relation,  or  conversion  declaration  of  that  type. 

The  following  additional  undesired  event  can  occur  when  an  STE  access  program  is  invoked. 
%%unknown  STE  program%% 

AT.STE.2.5.I  Operations  on  the  STE  Entities 


Program  name 

'/TTuIfr ^$SSSIj 

Parm  info 

Undesired  events 

+'set'+ 

pl:STEtype;I 

p2:boolean;0 

entity  to  test 
destination 

+ IS  'relation' + 

pl,p2:STEtype;I 

p4:(parms);I_OPT 

p3:boolean;0 

pair  to  test 

n-tuple 

destination 

%%unequal  lists%% 

+ 'relation' + 

pi:STEtype;0 

p2:(parms);I_OPT 

domain  elements 
n-tuple 

%%unequal  lists%% 
%out  of  domain% 

+ 'conversion  1'+ 

pl:STEtype;l 

p2:convtype;0 

value  to  convert 
destination 

+  'conversion2’+ 

pl:convtype;I 

p2:STEtype;0 

value  to  convert 
destination 
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+'set'+ 


p2  :•  (pi  is  an  element  of  the  set  attribute  whose 
identifier  is  'set') 


+  IS_'relation'+  p3  ((p4,pl),p2)  is  an  element  of  the  relation 

attribute  whose  identifier  is  'relation'.  If  p4  is 
omitted,  then  p3  (pl,p2)  is  an  element  of  'relation'. 

+ 'relation'-!-  pi  changes  state  to  s2  such  that  si  is  the  value  of  pi 

before  the  call,  vl,  ...  ,  vn  is  the  value  of  p2  (if 
given),  and  the  ordered  pair  (((vl,  ...  ,  vn),sl),s2)  (or 
(sl,s2)  where  p2  is  omitted)  is  an  element  of  the 
relation  attribute  whose  identifier  is  'relation'. 

Where  there  is  more  than  one  ordered  pair  with  the  same 
first  element,  any  may  be  chosen. 

+ 'conversion  1'+  p2  x  such  that  (pl,x)  is  an  element  of  a  conversion 

relation,  and  'conversionl'  is  the  first  of  the  ordered 
pair  of  identifiers  associated  with  that  conversion 
definition. 


+'conversion2'+  p2  x  such  that  (x,pl)  is  an  element  of  a  conversion 
relation,  and  'conversion2'  is  the  second  of  the  ordered 
pair  of  identifiers  associated  with  that  conversion 
definition. 


AT.STE.2.S.2  Await  Operations 

In  this  section  "AWAIT.T/F. 'string1*  stands  for  two  names,  "AW  AIT.T.  'string'"  and 
"AWAIT.F. 'string1".  Similarly,  in  the  effects  section,  alternate  phrasing  for  each  member  of  the  pair  is 
separated  by "/". 

Program  name  Parm  type  Parm  info  Undesired  events 

+AWAIT@’relation'+  pl:STEtype;I  variable  to  watch 

p2:(parms);I_OPT  n-tuple 

+  AWAIT@ —  'relation'+  pl:STEtype;I  variable  to  watch 

p2:(parms);I_OPT  n-tuple 

+  AWAIT.T/F.'set'+  pl:STEtype;I  candidate  member 

+  AWAIT.T/F. 'relation'-!-  pl,p2:STEtype;I  candidate  pair 

p3:(parms);l_OPT  n-tuple 

Program  Effects 

+  AWAIT@'relation'+  Let  p2' be  the  value  of  parameter(s)  p2.  Then,  all 

action  in  the  calling  process  is  suspended  until  pi 
undergoes  a  state  change  from  si  to  s2  such  that  the 
ordered  pair  ((p2',sl),s2)  (or  (sl,s2)  if  p2  is 
omitted)  is  an  element  of  the  relation  attribute  whose 
identifier  is  'relation'. 
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+  AWA1T@  = 'relation' +  If  p2  is  omitted,  then  all  action  in  the  calling 

process  is  suspended  until  the  access  program 
+  'relation'+ (pi)  is  executed.  Otherwise,  let  p2'  be 
the  value  of  p2.  Then  all  action  in  the  calling 
process  is  suspended  until  the  access  program 
+  'relation'+(pl,p2)  is  executed  with  p2  =  p2'. 

+  AWAIT.T/F.'set'+  If  the  value  of  pi  is/ (is  not)  a  member  of  the  set 

attribute  whose  identifier  is  'set',  the  call  has  no 
effect.  Otherwise,  all  action  in  the  calling  process 
is  suspended  until  the  value  of  pi  is/  (is  not)  a 
member  of  'set'. 

+  AWAIT.T/F.'relation'+  Let  p3'  be  the  value  of  parameter(s)  p3.  Then,  all 

action  in  the  calling  process  is  suspended  until  the 
ordered  pair  of  values  given  by  ((p3',pl),p2)  (or 
(pl,p2)  if  p3  is  omitted)  is/ (is  not)  a  member  of  the 
relation  attribute  whose  identifier  is  'relation'.  If 
the  ordered  pair  of  values  is/  (is  not)  already  a 
member  of  'relation',  the  call  has  no  effect. 

AT.STE.3  Undesired  Event  Assumptions 

1.  Users  wi.l  not  supply  an  argument  to  a  conversion  outside  of  the  domain  of  the  defining 
relation. 

AT.STE.4  Local  Type  Definitions 

Local  types  that  are  used  in  the  description  of  programs  specified  in  EC.DATA  and  are  not 
described  here  are  defined  in  Section  EC.DATA. 4.  In  the  following  definitions,  where  the  syntax  is 
given  in  modified  BNF,  alphabetic  strings  contained  in  quotation  marks  (e.g.,  "state")  are  terminal  sym¬ 
bols.  Ellipses  (e.g.,  state,  ....  state)  denote  a  list  of  two  or  more  elements  separated  by  commas. 

attribute  The  attributes  of  an  STE  type  characterize  the  type. 

The  syntax  of  an  STE  type  attribute  is, 

("state"  (statejist) 

££  ("relation"  (relation_defn)) 
j2I  ("set"  (set_defn)) 
or  ("conversion"  (conversion_defn)) 

An  STE  type  declaration  must  have  exactly  one  "state" 
attribute.  There  may  be  any  number  of  the  remaining 
attributes. 

attributes  ::*■  attribute  or  attribute,  attributes. 

convtype  An  entity  of  the  specific  type  specified  in  the 

conversion_defn. 

conver^ion  defn  A  1:1  mapping  between  a  subset  of  the  states  of  an  STE 

type  and  a  set  of  literals  of  another  type.  The 
syntax  is. 


relation  defn 


set  defn 
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(ID, ID),  typeJD  (sl,tl) 
or  (ID,ID),  type_ID  ((sl,ll),  .  .  .  ,  (sn,tn)) 

where  type_ID  is  the  identifier  of  a  specific  type, 
each  of  the  subsequent  ordered  pairs  must  be  of  the 
form: 

(STE  literal,  x)  or  ((STE  literal . STE  literal),  x) 

where  x  is  a  literal  or  constant  of  typeJD.  The 
ordered  pair  (ID, ID)  identifies  the  conversion 
programs  from  the  STE  type  and  to  the  STE  type, 
respectively. 

An  identifier  associated  with  an  STE  attribute. 

A  list  of  entities  separated  by  commas.  The  number  of 
entities  and  their  types  must  match  those  of  the 
n-tuple  "P"  in  the  corresponding  relation_defn. 

A  set  of  ordered  pairs  of  the  form  ((P,D),R)  where 
(P,D)  is  an  element  of  the  domain  of  the  relation 
being  defined  and  R  is  an  element  of  the  range.  D  and 
R  must  be  m-tuples  of  elements  of  the  state  set.  P 
may  be  an  n-tuple  of  literals  of  any  type.  P  may  be 
omitted  in  which  case,  the  ordered  pairs  are  written 
(D,R).  The  syntax  is, 

ID  (ordered_pairs) 

ordered_pairs  (domain,  statejist) 
or  (domain,  statejist),  ....  (domain,  statejist) 

domain  —  statejist 
or  (literals,  statejist) 

literals  literal 
or  (literal,  .  .  .  ,  literal) 

The  relation  "EQ"  is  automatically  defined  for  all  STE 
types.  It  is  defined  as  the  set  of  ordered  pairs 
(s,s)  where  s  is  an  n-tuple  of  elements  of  the  state 
set. 

The  relation  "SET"  is  automatically  defined  for  all 
STE  types.  It  is  defined  as  the  set  of  all  ordered 
pair  ((s2,sl),s2)  where  si  and  s2  are  lists  of 
elements  of  the  state  set. 

A  subset  of  the  set  of  states  of  the  STE  type  being 
defined  or  a  subset  of  the  power  set  of  the  set  of 
states.  The  syntax  is, 

::*■  ID,  statejist 
or  ID  (statejist,  .  .  .  ,  statejist). 

An  STE  literal  (i.e.,  state  name). 
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statejist  ::=  state  or  (state,  .  .  .  ,  state) 

STE  type  An  entity  of  the  STE  type  for  which  the  operation  is 

defined  or  a  list  of  such  entities  enclosed  in 
parentheses  and  separated  by  commas. 


AT.STE.5  Dictionary 
None. 

AT.STE.6  Undesired  Event  Dictionary 

%%duplicate  set  member%% 

%%inappropriate  parameters%% 

%%malformed  attribute%% 

%%missing  state  attribute%% 
%out  of  domain% 

%%too  many  state  attributes%% 
%%type  inconsistency%% 
%%undeclared  spectype%% 
%%unequal  lists%% 

%%unknown  state%% 

%%unknown  STE  program%% 


A  user  program  has  specified  a  set  with 
duplicate  elements. 

A  user  program  has  called  an  access  program 
with  parameters  that  do  not  correspond  in 
specific  type  to  the  declaration. 

The  user  has  supplied  an  attribute 
declaration  with  a  syntax  inconsistent  with 
that  specified  in  AT.STE.4. 

A  user  program  has  declared  an  STE  type  with 
no  "state"  attribute. 

A  user  program  has  supplied  an  input 
parameter  that  is  not  in  the  domain  of  the 
relation. 

A  user  program  has  declared  an  STE  type  with 
more  than  one  "state”  attribute. 

A  user  program  has  supplied  a  conversion 
value  not  of  the  specified  type. 

A  user  program  has  specified  a  specific  type 
that  has  not  been  defined. 

A  user  program  has  supplied  a  list  parameter 
that  does  not  match  the  specified  length. 

A  user  program  has  provided  a  state  value 
that  has  not  been  declared  in  the  "state" 
attribute. 

A  user  program  has  specified  an  STE  program 
that  does  not  correspond  to  any  attribute 
identifier  that  has  been  defined  for  the 
type. 
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AT.STE.7  System  Generation  Parameters 

None. 

AT.STE.8  Information  Hidden 

1.  Internal  representation  of  states,  sets,  and  relations. 

2.  Algorithms  used  in  the  programs  corresponding  to  AT  attributes. 

3.  How  processes  await  a  state  transition  event  and  how  they  are  restarted. 
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AT.INDEX  INDICES  TO  THE  DOCUMENT 

This  section  provides  the  following  indices  to  the  facilities  described  in  this  document 

Access  Programs 
Local  Type  Definitions 
Dictionary  Terms 
Undesired  Events 


Facilities  specified  in  [EC]  are  not  included  in  this  index. 


Access  Programs 


Program  name 

Where  defined 

+  ACCEL  R  FPSS  + 

AT.NUM 

+  ACCEL  R  G  + 

AT.NUM 

+  ANGLE  R  CIR  + 

AT.NUM 

+ ANGLE  R  COS  + 

AT.NUM 

+ ANGLE  R  DEG  + 

AT.NUM 

+  ANGLE  R  RAD  + 

AT.NUM 

+  ANGLE  R  SIN  + 

AT.NUM 

+ ANGLE  R  SINCOS  + 

AT.NUM 

+ ANGRATE  R  DEGHOUR+ 

AT.NUM 

+ ANGRATE  R  RADSEC  + 

AT.NUM 

+CYL  VECTOR + 

AT.NUM 

+  DENSITY  R  SLCUFT  + 

AT.NUM 

+  DISTANCE  R  FT  + 

AT.NUM 

+  DISTANCE  R  NMI  + 

AT.NUM 

+  PRESSURE  R  INHG  + 

AT.NUM 

+  R  ACCEL  FPSS  + 

AT.NUM 

+  R  ACCEL  G  + 

AT.NUM 

+R  ANGLE  CIR  + 

AT.NUM 

+R  ANGLE  COS+ 

AT.NUM 

+  R  ANGLE  DEG  + 

AT.NUM 

+R  ANGLE  RAD  + 

AT.NUM 

+  R  ANGLE  SIN  + 

AT.NUM 

+R  ANGRATE  DEGHOUR+ 

AT.NUM 

+  R  ANGRATE  RADSEC  + 

AT.NUM 

+  R  DENSITY  SLCUFT+ 

AT.NUM 

+R  DISTANCE  FT+ 

AT.NUM 

+  R  DISTANCE  NMI  + 

AT.NUM 

+R  PRESSURE  INHG  + 

AT.NUM 

+  R  SPEED  FPM  + 

AT.NUM 

+  R  SPEED  FPS  + 

AT.NUM 

+  R  SPEED  KNOT  + 

AT.NUM 

+ SPEED  R  FPM  + 

AT.NUM 

+SPEED  R  FPS  + 

AT.NUM 
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+SPEED_R  KNOT 4-  AT.NUM 

+SPHER  VECTOR  +  AT.NUM 

+VECTORCYL+  AT.NUM 

+  VECTOR  SPHER+  AT.NUM 

+VECTOR_XYZ+  AT.NUM 

+XYZ_VECTOR  +  AT.NUM 


In  addition,  AT.STE  allows  the  user  to  define  access  programs  of  the  following  form: 

+ A  W  AIT@  relation + 

+  AW  AIT  @  «■  relation  + 

+ AWAIT.  T/F.set+ 

+  AWAIT.T/F.relation+ 

+conversionl  + 

+conversion2  + 

+ relation  +  (4  parameters) 

+ relation +  (2  parameters) 

+set+ 


Local  Type  Definitions 


Type  name 

Where  defined 

accel 

AT.NUM 

accel-vec 

AT.NUM 

angle 

AT.NUM 

angrate 

AT.NUM 

attribute 

AT.NUM,  AT.STE 

attributes 

AT.STE 

convtype 

AT.STE 

conversiondefn 

AT.STE 

density 

AT.NUM 

displacement 

AT.NUM 

distance 

AT.NUM 

parms 

AT.STE 

pressure 

AT.NUM 

relation.defn 

AT.STE 

set_defn 

AT.STE 

speed 

AT.NUM 

state_set 

AT.STE 

STEtype 

AT.STE 

STEtype_list 

AT.STE 

typeclass 

AT.NUM 

velocity 

AT.NUM 

version 

AT.NUM 

Dictionary  Terms 

Term 

Where  defined 

f+ magnitude  +  1 

AT.NUM 

!+phi+! 

AT.NUM 

!+ radius +  ! 

AT.NUM 

!+theta+! 

AT.NUM 
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!  +  vector  + ! 

!-f-X  component  + ! 
!  +  Y  component +  ! 
!+Z  component +  ! 


AT.NUM 
AT.NUM 
AT  NUM 
AT.NUM 


Undesired  Events 


UE  name  Where  defined 

%%duplicated  set  member%%  AT.STE 

%illegal  sin  or  cos  given%  AT.NUM 

%%inappropriate  parameters%%  AT.STE 

%%malformed  attribute%%  AT.STE 

%%missing  state  attribute%%  AT.STE 

%out  of  domain%  AT.STE 

%range  exceeded%  AT.NUM 

%%too  many  state  attributes%%  AT.STE 

%%type  inconsistency%%  AT.STE 

%%undeclared  spectype%%  AT.STE 

%%unequal  lists%%  AT.STE 

%%unimplemented  binding%%  Appendix  4 

%%unimplemented  attribute 
via  variables%%  Appendix  4 

%%unknown  state%%  AT.STE 

%%unknown  STE  program%%  AT.STE 
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Appendix  1 

INTERFACE  DESIGN  ISSUES 


AT.NUM 

1.  Although  AT  and  EC  designers  are  critically  concerned  with  which  facilities  are  machine- 
dependent  and  which  are  not,  we  felt  that  users  of  the  resulting  modules  would  not  be  as  con¬ 
cerned.  Therefore,  we  tried  to  design  this  module  so  that  users  could  regard  it  as  an  extension  to 
the  Extended  Computer;  the  AT  and  EC  in  conjunction  provide  the  basic  programming  environ¬ 
ment  for  the  rest  of  the  system.  We  tried  to  make  the  design  as  parallel  to  EC. DATA  as  possible, 
in  order  to  present  in  effect  a  single  kind  of  interface  to  programmers  interested  in  manipulating 
data  of  any  type. 

2.  We  thought  that  registers  for  abstract  data  types  would  not  be  useful.  If  they  turn  out  to  be  desir¬ 
able,  however,  the  facility  would  be  a  straightforward  extension,  based  on  the  EC  architecture. 

3.  Any  design  issue  in  EC. DAT  A  concerning  facilities  or  designs  copied  by  this  module  naturally 
also  applies  to  this  module. 

4.  We  could  have  allowed  a  sine/cosine  pair  for  an  angle  literal.  However,  to  keep  the  interface  sim¬ 
ple  and  consistent,  we  do  not  allow  literals  to  be  given  in  this  two-part  manner. 

5.  We  used  to  have  an  abstract  data  type  called  "mach",  using  it  to  represent  a  speed  relative  to  the 
speed  of  sound.  But  it  produced  so  many  hard  questions  (e.g..  When  you  divide  a  speed  by  a 
speed,  do  you  get  a  real  or  a  mach?  How  can  you  check  at  compile-time?  If  the  speed  you  com¬ 
pare  with  is  the  speed  of  sound  at  some  other  altitude/pressure/temperature,  is  the  result  a  mach 
or  not?)  that  we  decided  it  was  not  really  an  abstract  data  type  like  the  others. 

AT.STE 

1.  Originally,  the  AT  module  included  only  the  synchronization  operations  +SIGNAL+  for  wg*'  *- 
ing  the  occurrence  of  events  and  +  AWAIT  +  for  allowing  processes  to  wait  for  the  occu*rfcjTi.e  of 
events.  These  operations  were  chosen  because  they  support  the  notion  of  events  in  the  OFP 
specifications. 

These  operations  originally  were  part  of  the  EC  interface.  They  were  moved  to  the  AT  module 
because  (a)  they  can  be  constructed  by  using  the  +UP  +  ,  +DOWN  +  ,  and  +PASS+  operations 
provided  by  the  EC;  (b)  the  EC  synchronization  operations  would  not  be  made  simpler  by  using 
+  AWAIT 4-  and  -1-SIGNAL +  ;  (c)  we  could  think  of  useful  systems  that  did  not  need 
+  AWAIT 4-  and  +SIGNAL  +  ;  and  (d)  it  made  the  EC  interface  simpler 

2.  It  was  noted  that,  in  some  cases,  processes  needed  to  wait  if  the  system  was  not  in  a  particular 
state  but  did  not  need  to  wait  if  the  the  system  was  already  in  the  desired  state.  (Here  and  in  the 
following  paragraphs,  "state  of  the  system"  is  used  to  mean  a  particular  system  state  or  a  class  of 
such  states.)  Simple  event  variables  could  not  be  used  in  this  case  since  the  event  associated  with 
the  system- entering  a  state  would  not  be  signaled  until  the  state  had  been  left  and  entered  again. 
To  solve  this  problem,  we  added  an  additional  event  variable  to  the  interface  called,  an  "event 
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boolean"  and  an  addilional  await  operator.  Processes  could  wait  on  the  event  of  a  state  change  in 
an  event  boolean  using  the  +  AWAIT  +  operator.  The  new  operator,  +AWAITC+  (await  on 
condition),  caused  the  process  to  wait  only  if  the  event  boolean  was  not  in  the  specified  state.  If 
the  event  boolean  was  already  in  the  specified  state,  the  calling  process  continued  without  inter¬ 
ruption.  This  allowed  processes  to  respond  to  an  event  that  occurred  while  the  process  was  active. 
This  facility  was  later  superceded  (see  4). 

3.  The  specifications  require  that  processes  be  able  to  wait  on  the  occurrence  of  complex  events,  for 
instance,  the  disjunction  of  two  or  more  events  or  the  occurrence  of  an  event  while  the  system  is 
in  a  particular  state  (i.e.,  @T(event)  WHEN  (condition  AND  condition  AND  .  .  .)).  Complex 
synchronization  conditions  could  not  be  implement  directly  with  even  booleans,  so  we  attempted 
to  provide  a  syntax  for  expressing  complex  events  and  a  synchronization  mechanism  for  interpret¬ 
ing  that  syntax.  Users  of  the  synchronization  module  would  express  the  complex  event  for  which 
they  wanted  to  wait  in  the  syntax  provided  by  this  module.  The  module  would  interpret  the 
requests,  translate  them  into  more  primitive  synchronization  operators,  and  signal  the  appropriate 
events. 

This  scheme  proved  inadequate  for  several  reasons.  The  synchronization  module  proved  to  be 
large  and  complicated.  The  interpretation  mechanism  was  complex  and  difficult  to  implement. 
The  proposed  mechanism  still  did  not  solve  all  of  the  problems  associated  with  waiting  for  com¬ 
plex  events. 

a.  If  user  processes  were  awaiting  a  disjunction  of  events,  they  could  not  distinguish  which 
event  had  been  signaled.  Processes  could  not  perform  conditional  actions  based  on  the 
awakening  event  without  checking  the  values  of  extra  variables.  Even  with  very  short 
deadlines,  these  values  could  change  before  they  were  checked. 

b.  Processes  waiting  on  events  with  WHEN  clauses  frequently  needed  to  know  if  the  condi¬ 
tions  expressed  in  the  WHEN  clause  still  held  by  the  time  they  began  running.  These 
processes  would  have  to  recheck  the  condition  values  after  they  began  running. 

c.  Since  the  events  that  processes  awaited  did  not  necessarily  reflect  the  state  of  the  system 
by  the  time  they  began  running,  the  order  in  which  these  events  had  occurred  could  not 
necessarily  be  determined.  Processes  that  needed  to  run  in  a  particular  order  depending 
on  the  order  of  events  were  not  able  to  do  so. 

By  using  even  variables  and  event  booleans,  these  problems  could  be  solved  only  by  providing 
great  numbers  of  small  short-deadline  processes  that  recorded  the  occurrences  of  events  in  local 
variables. 

4.  STE  variables  were  proposed  as  a  replacement  for  event  variables  and  event  booleans.  Users  can 
define  event  variables  with  more  than  two  states  and  can  wait  on  state  change  events  or  transitions 
between  states.  This  mechanism  allows  us  to  solve  those  problems  listed  in  3,  where  the  class  of 
states  is  small  enough  to  describe  by  enumeration  and  the  transition  time  between  states  is  large 
enough  that  the  changes  can  be  recorded  by  the  event  detection  mechanism;  for  instance; 

a.  Event  booleans  are  unnecessary  since  they  can  be  implemented  with  STEs. 

b.  STEs  provide  a  single  mechanism  for  signaling  transitions  in  variables  with  more  than  two 
discrete  states. 
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c.  A  syntax  for  expressing  awaits  on  complex  events  is  unnecessary.  A  state  of  an  STE  vari¬ 
able  can  be  associated  with  the  occurrence  of  a  complex  event,  and  the  user  process  need 
only  wait  on  the  transition  to  that  state. 

d.  User  processes  can  wail  on  a  disjunction  of  events  and  determine  which  event  caused  the 
signal  by  examining  the  value  of  an  STE  variable. 

e.  STEs  can  record  the  "history"  of  events  in  their  transitions.  In  those  cases  where  the  his¬ 
tory  can  be  represented  by  an  enumerated  set  of  states  and  transitions,  STEs  allow  the 
user  processes  to  respond  to  events  in  the  order  of  their  occurrence  and  to  events  that 
have  occurred  while  they  were  running.  Additional  processes  need  not  be  created  to  per¬ 
form  these  tasks. 

f.  Processes  can  signal  different  events  to  different  users  by  causing  a  transition  in  a  single 
STE  variable. 

Originally,  the  STE  module  provided  comparison  operators  for  STE  values  and  set  membership 
operators  and  conversion  operators.  We  found  that  users  of  the  module  frequently  only  needed  a 
small  subset  of  the  operations  provided.  By  allowing  the  creator  of  the  STE  type  to  define  the 
operations  needed,  the  required  subset  of  operations  can  be  selected  without  incurring  overhead 
for  unneeded  ones. 

Originally  the  STE  module  provided  for  one  explicit  ordering  on  a  given  STE  domain.  The  com¬ 
parison  operators  provided  referred  to  that  ordering.  We  decided  that  such  an  ordering  was 
unnecessary  as  it  can  be  implemented  as  a  special  case  of  a  relation. 
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Appendix  2 

IMPLEMENTATION  NOTES 

AT.NUM 

None. 

AT.STE 

None. 


Appendix  3 

BASIC  ASSUMPTIONS 


AT.NUM 

All  basic  assumptions  in  EC.  DAT  A. 3.1  apply,  except  those  that  explicitly  mention  bitstrings, 

registers,  or  time  intervals.  Where  an  EC. DATA  assumption  mentions  the  Extended  Computer  or  EC, 

readers  of  this  module  should  substitute  “Application  Data  Types  module"  or  "AT,"  respectively.  In 

addition,  the  following  assumptions  apply  to  this  module: 

1 .  For  each  scalar  type  class  provided,  there  is  a  fixed  set  of  units  of  measurement  into  which  values 
of  that  class  may  be  converted.  The  units  for  each  type  class  are  listed  in  Table  AT.NUM.a. 
Values  of  vector  type  classes  may  be  converted  into  component  scalar  values,  or  a 
direction/ magnitude  equivalent. 

2.  User  programs  may  not  make  assumptions  about  the  representation  of  numeric  values.  Even 
though  literals  are  expressed  in  particular  units,  there  is  no  implication  that  the  value  is  stored  in 
those  units. 

3.  The  only  operations  needed  for  calculating  new  numeric  values  are:  addition,  multiplication,  divi¬ 
sion,  subtraction,  absolute  value,  and  complement.  In  addition,  we  need  to  convert  scalars 
to/from  reals,  and  vectors  to/from  component  scalars. 

4.  We  need  arrays  of  numeric  data  types  in  which  the  attributes  of  an  element  can  change  indepen¬ 
dently  of  the  attributes  of  other  elements. 

5.  The  range  and  resolution  of  each  numeric  variable  can  be  determined  at  the  time  the  system  is 
generated. 

6.  Arithmetic  operations  involving  operands  of  different  type  classes  may  or  may  not  have  a  useful 
physical  meaning.  Those  that  do  are:  speed  “  distance/time,  distance  —  speed*time,  time  — 
distance/speed,  angrate  =  angle/time,  angle  -  angrate*time,  time  *  angle/angrate,  accel  — 
speed/time,  speed  "  accel*time,  time  *  speed/accel,  velocity  =■  displ/time,  displ  *- 
velocity'time,  time  “  displ/velocity,  accel-vec  —  velocity/time,  velocity  —  accel-vec*time,  and 
time  —  velocity/accel-vec. 

Further,  if  a  value  of  any  type  class  is  multiplied  or  divided  by  a  real,  the  result  has  the  same  type 
class. 

AT.STE 

1.  State  transitions  may  be  considered  to  be  instantaneous. 

2.  When  processes  need  to  wait  for  particular  states  to  occur,  they  do  not  need  to  proceed  while 
waiting.  The  states  for  which  the  process  is  waiting  can  be  determined  before  the  process  begins 
to  wait. 
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3.  If  a  process  is  awaiting  a  state  change,  it  need  not  proceed  until  the  change  occurs.  The  transi¬ 
tions  for  which  the  process  is  waiting  can  be  determined  before  the  process  begins  to  wait. 

4.  There  is  no  need  for  a  mechanism  that  allows  a  process  to  be  started  before  the  state  or  transition 
that  has  been  specified  in  an  AWAIT  operation  has  occurred. 
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Appendix  4 

UNIMPLEMENTED  APPLICATION  DATA  TYPE  FACILITIES 


Not  all  of  the  capabilities  described  in  this  report  have  been  provided  in  the  current  version  of  the 
implementation.  A  few  facilities,  which  are  not  currently  needed  by  the  application  program,  have  not 
been  implemented.  An  attempt  to  use  an  absent  facility  will  result  in  an  undesired  event  in  the 
development  version.  The  unimplemented  features  are  described  below. 

Feature:  Specific  types  with  attributes  that  can  vary  at 

run-time 

Where  Described:  AT.NUM. 

Undesired  Event:  %%unimplemented  binding%%. 

Current  Use.  In  the  +-  +  DCL  TYPE+  +  program,  users  may  not  declare  the 
binding  of  bitstring  or  timeint  specific  types  to  be 
VARY.  In  the  +  +  DCLJENTITY  +  +  and  +  +DCL  ARRAY  +  + 
programs,  users  may  not  provide  an  initial  attribute. 

Using  variables  to  specify  attributes  of  a  specific 
type,  or  of  a  variable  or  array  with  varying  attributes. 

AT.NUM. 

%%unimplemented  attribute  via  variables%%. 

To  specify  an  attribute  (as  defined  in  AT.NUM.4), 
literals  or  constants  must  be  used. 


Feature: 

Where  Described: 
Undesired  Event: 
Current  Use: 
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Appendix  S 

DATA  REPRESENTATION  (VERSION)  CATALOG 


For  some  numeric  data  types,  the  Application  Data  Types  module  can  provide  more  than  one 
kind  of  representation.  The  version  has  no  effect  on  the  outcome  of  an  operation,  but  some  versions 
allow  some  operations  to  be  performed  more  quickly  than  other  versions. 

The  version  catalog  lists  the  provided  version  names  for  each  AT  data  type  which  has  more  than 
one  version.  When  declaring  a  specific  type,  users  may  request  a  particular  version  by  using  these 
names. 

Users  referred  to  the  version  catalog  in  Appendix  6  of  [ECl.  Versions  of  real  types  named  there 
are  available  from  this  module  as  well. 
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